Problem: /actuator/health on a running `code-iq serve` returned HTTP 503
with body {"groups":["liveness","readiness"],"status":"OUT_OF_SERVICE"},
even after the graph was fully loaded and /api/stats was returning real
data. This made the health endpoint unusable for K8s/Compose readiness
probes and confused baseline smoke-tests.

Root cause: ServeCommand.call() blocks on Thread.currentThread().join()
inside Spring Boot's CommandLineRunner.run(). Because the runner never
returns, Spring's ApplicationReadyEvent is never published, and neither
is the default AvailabilityChangeEvent that normally transitions
ReadinessState from REFUSING_TRAFFIC to ACCEPTING_TRAFFIC. With the
serving profile's probes enabled, the aggregated health endpoint stays
pinned at OUT_OF_SERVICE forever.

Fix: ServeCommand now explicitly publishes the two availability events
via a new markReady() method before blocking:

    AvailabilityChangeEvent.publish(events, this, LivenessState.CORRECT);
    AvailabilityChangeEvent.publish(events, this, ReadinessState.ACCEPTING_TRAFFIC);

markReady() is extracted for testability. A new ServeCommandTest case
verifies both events are published in the documented order.

Verified end-to-end against both seed repos via the updated pipeline
script: /actuator/health now returns HTTP 200 with status "UP".

  | seed                | ready  | health_http | before |
  |---------------------|-------:|------------:|-------:|
  | spring-petclinic    |  13s   |    200      |  503   |
  | realworld-express   |  14s   |    200      |  503   |

Follow-up (out of scope): GraphBootstrapper's
@eventlistener(ApplicationReadyEvent.class) is effectively dead code
for the same reason — the listener never fires because the event never
fires. Only not-a-bug today because enrich always runs before serve in
our pipeline, so the bootstrap fallback never actually needs to trigger.